Video stream sharing

ABSTRACT

A method and apparatus to allow multiple users to share a common stream of video information while providing each user the ability to have video-motion-control without interrupting the video program material viewed by the remaining users sharing the stream of video information. Also included is a method and apparatus to maximize the availability of video information in a given video content library which minimizing the storage media required to store the video information contained therein.

CROSS-REFERENCES TO RELATED APPLICATIONS

This application is a continuation of co-pending nonprovisionalapplication Ser. No. 09/227,030, filed Jan. 7, 1999, entitled VideoStream Sharing, which is a nonprovisional application of U.S.provisional patent application Ser. Nos. 60/070,739, filed Jan. 8, 1998,and 60/072,004, filed Jan. 21, 1998, both of which are entitled “ALLDEMAND VIDEO SERVER,” have Winston W. Hodge listed as an inventor andare assigned to StreamGate Video, Inc. patent application Ser. Nos.09/227,030, 60/0070,739 and 60/072,004 are incorporated by reference intheir entirety.

BACKGROUND OF THE INVENTION

The present invention relates to distribution of information eitherthrough broadcasting transmission over a local or wide area network,e.g., the Internet, or using cable video systems. More particularly, theinvention provides a technique, including a method and apparatus, forscheduling distribution of video/audio information so as to maximizeviewer ship of the same and, therefore, profits.

High speed networking and mass storage technologies have made possibleinteractive communication networks which provide consumers withvideo/audio information. Broadcast, video-on-demand, pay-per view, cableand Internet services are some of the best known services for providingconsumers with programming choices ranging from movies to interactivegames. FIG. 1 shows the major components of a video on demand service.The video programs, such as movies, are typically stored in one ofvarious formats at a central server 10. Subscribers 12 submits requeststo the server 10 for particular programs over a communications network14. The communications network 14 may use any transmission medium, e.g.commercial telephone, cable and satellite networks. Upon receiving arequest, server 10 retrieves the video program from mass storage anddelivers a data stream, corresponding to the frames of the movie, to therequesting subscriber via distribution network 14. The data stream isdirected to a receiver possessed by the subscriber which converts thedata stream into signals necessary for playback and viewing of themovie.

With conventional video-on-demand video distribution, a library ofcontent for selection by the user and complete Video Motion Control(VMC) is provided. VMC features typically include functions such aspause, fast forward, forward scan, reverse and reverse scan. Additionalenhancements made possible via digital VMC implementation could includescene and chapter searches, searches for specific content, contentrelated shopping and research, and other database type functions. Tothat end, conventional video-on-demand, conventionally known as truevideo on demand, dedicates a single session or communication pathwaybetween the viewer and his movie. The communication pathway typicallyconsists of dedicated video streams from a recording medium, such as adisk, dedicated communications channels, switching infrastructure, localneighborhood nodes, and set top boxes, disposed proximate to the localneighborhood nodes.

The dedication of communication pathways limits the number of customersthat may be serviced by a providers, thereby reducing the revenue thatmay be generated. The number of viewers that may receive a common streamof video information, and the components and subsystems needed totransmit the same, is limited to a single user. As a result, the priorart is replete with systems and methods of maximizing the revenuegenerated by a given bandwidth of transmission channels. For example,U.S. Pat. No. 5,758,257 to Hertz et al. and U.S. Pat. No. 5,734,720 toSalganicoff each discloses a system and a method for scheduling receiptof desired movies and other forms of data from a network whichsimultaneously distributes many sources of such data to many customers,as in a cable television system. Customer profiles are developed for therecipient describing how important certain characteristics of thebroadcast video program, movie or other data are to each customer. Fromthese profiles, an “agreement matrix” is calculated by comparing therecipient's profiles to the actual profiles of the characteristics ofthe available video programs, movies or other data.

U.S. Pat. No. 5,594,491 to Hodge et al., assigned to the assignee of thepresent invention, discloses a system and method for distributing videoover ADSL telephone lines. To maximize usage of the bandwidth providedby a system storing the information to be distributed, Hodge et al.advocate implementing a Near-Video-On Demand (NVOD) protocol. The NVODprotocol maps a video program onto a disk-drive in an interleavedfashion so that the video program is divided into data packets having aplurality of frames with each pair of adjacent frames corresponding to apair of frames in a viewing sequence displaced from one another by apredetermined number of frames. Mapping the video frames in this mannerrenders the system compatible with existing video distribution systems,while maximizing the number of users that may access any given program.

U.S. Pat. No. 5,172,413 to Bradley et al. describes, in pertinent part,use of a central electronic library to store and deliver high-demandentertainment programming to local community electronic libraries thatchannel the programming to subscribers.

Low-demand programming is stored and delivered directly from a localcommunity electronic library located in an area in which there may be aspecial interest in the programming. In this manner, Bradley et al.maximize access capacity while minimizing investment cost.

U.S. Pat. No. 5,421,031 to De Bey describes, in pertinent part, avideo-on-demand system in which a video program disposed on anon-volatile storage device in divided into a plurality of segments. Thesegments are transmitted to each subscriber as a redundant sequence. Thesequence is transmitted in accordance with a scheduling algorithm thatensures all the video segments of the video program are received by thesubscriber to enable continuous playback in real-time of the videoprogram. In this manner, the segments typically correspond to anon-contiguous sequence of video frames. The receiver, possessed by thesubscriber, includes a buffer having sufficient memory to store asufficient amount of video segments to ensure the subscriber experiencesreal-time playback of the video program.

What is needed, however, is a system and method for maximizing thenumber of users that may share a common communication pathway of data.

SUMMARY OF THE INVENTION

The present invention provides a method and apparatus to allow multipleusers to share a common stream of video information while providing eachuser the ability to have video-motion-control without interrupting thevideo program material viewed by the remaining users sharing the streamof video information. Also included is a method and apparatus tomaximize the availability of video information in a given video contentlibrary while minimizing the storage media required to store the videoinformation contained therein.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a simplified block diagram of a prior art video-on-demanddistribution system;

FIG. 2 is a simplified block diagram of a multi-session video-on-demandarchitecture;

FIG. 3 is a table demonstrating the increase in users per channelemploying stream sharing using the architecture shown above in FIG. 2;

FIG. 4 is a graphical representation showing a comparison of theefficiency between single-session video-demand architecture vs.multi-session video-on-demand architecture;

FIG. 5 is a graph depicting possible statistical viewing assumptions inaccord with the present invention;

FIG. 6 is a graphical representation of contractual constraints whichare quantified and operated on by the management workstation of FIG. 2;

FIG. 7 is a multiple adaptive threshold element for automatic shelfspace allocation, in accord with the present invention;

FIG. 8 is a block diagram showing an all demand video architecture inaccord with the present invention; and

FIG. 9 is a graph showing the different video distribution techniquesthat may be achieved by the all demand video architecture shown above inFIG. 8.

DESCRIPTION OF THE SPECIFIC EMBODIMENTS

Referring to FIG. 2, an embodiment of a multi-session video-on-demandarchitecture includes a management workstation 13 in data communicationwith one or more video distribution systems 16. The video distributionsystems 16 are in data communication with one or more end users 17. Boththe management workstation 13 and the video distribution systems 16 maybe remotely located with respect to the end users 17. To that end, themanagement workstation 13 typically includes one or more processors andassociated cache memory and related computer peripheral components thatare in data communication with each of the video distribution systems 16via, for example, an Ethernet connection. Each video distributionsystems 16 includes a digital video engine host/video pump DVEH/VP 16 aand a modulator/up-converter 16 b in data communication therewith via anOC3 link. The video distribution systems 16 are in data communicationwith the end users 17 over an existing communication infrastructure,such as the Internet, cable network system, television broadcast networkor satellite. A disk farm 15, or content storage library, contains videoprograms to be streamed to users 17. It should be understood that videoprograms are meant to include any type of digital information such asmovies, JPEG files, sound files and the like. The DVEH/VP 16 a cansaturate a 155 megabits per second OC3 optical delivery pipe thattranslates to approximately eight to twenty video streams. When morethan the eight to twenty video streams are typically required for agiven video program, multiple DVEH/VP 16 a are required to distributethe video program in the video library 15. One or more of the DVEH/VP 16a may be dedicated to feeding a single group of users 17 linked to acommon neighborhood node. This architecture provides the ability totransmit any video program to any user 17 subscriber via the DVEH/VP 16a's integrated PCI bus time division multiplexing and by the by thespace division facility of the N by M SCSI disk controller switches.

A transaction processor 19 is also in data communication with themanagement workstation 13 via an Ethernet link. The transactionprocessor 19 is connected to receive requests from users 17 vianeighborhood nodes 21 in data communication with the transactionprocessor 19 through return data path receivers 23 and amplifiers anddiplexors 25. The management workstation 13 may consist of one or morecomputers and functions to distribute information to the videodistribution systems 16 and control operation of the same, such ascontent installation, play rule determination, barker channel(advertisements) preparation, accounting, maintenance and the like. As aresult, the management workstation 13 classifies requests as eitherrequests for video content or video motion control and prioritizes therequests to determine the most efficient communication pathway, i.e.,which video distribution system 16, over which to transmit the videocontent to the subscriber. Optimization of the communication pathway iscomputed by the management workstation 13, with instructions sent to theappropriate DVEH/VP 16 a to be executed by the same.

Video-motion-control requests are also transmitted to the managementworkstation 13 which then determines management workstation resourcesthat may be allocated to the user 17 transmitting this request. To thatend, the management workstation allocates a subset of availablebandwidth of the communication link between the management workstation13, the DVEH/VP 16 a and the user 17 to facilitate video motion control.Upon termination of the video motion control bandwidth, the video motioncontrol resource is returned to the video motion control resource pool.

Important in determining the efficient communication pathway over whichto transmit information is ensuring that multi-session streaming, i.e.,shared video streaming is facilitated. To that end, the managementworkstation 13 selects the communication pathway to maximize the numberof users 17 that commence viewing of a program concurrently. In thisfashion, the number of users 17 that may view a video program ismaximized while minimizing resources, such as video distributionssystems 16, necessary transmit video content to the users 17.

For example, assume a multi-session video architecture supports 100,000users 17 and stores 100 different video programs in the content library15. On a given day, on a given hour, 10% of the subscribers request toview a video program. Assume that the video programs in the contentlibrary 15 are equally popular; therefore, 10,000 subscribers areselecting 100 video programs, i.e., or each video program is viewed by100 subscribers. Assume further that video program surfing (browsing) ismost prevalent a few minutes before and after the aforementioned hour,defining a window of viewing latency, and that each video program has aone minute interval consisting of an interesting frontal appendage,i.e., is not germane to the information, such as a plot/story-line ofcorresponding to the video program. This window of latency permits videostream sharing among multiple users 17 while waiting for the videoprogram to commence.

Referring to both FIGS. 2 and 3, this example is further demonstratedassuming a user 17 requests to view the video program entitled “My BestFriend's Wedding” at a few moments after 8:03 PM. Five seconds later(8:03:05 PM), three additional users 17 transmit requests to view thesame video program. At 8:03:10 PM, twelve additional users 17 selectthis video program and such selection continues until 86 viewers haverequested to view “My Best Friend's Wedding” before informationcorresponding to this video program is transmitted to a user 17, e.g.,before 8:04:00 PM, sixty seconds after a previous group of users 17commenced viewing “My Best Friend's Wedding”. In this manner, a windowof viewing latency having a sixty second interval is provided in whichmultiple users 17 can be cobbled into group to share a common stream ofvideo information. This provides a 16.5 multiplier of architectureefficiency, with is determined by summing the total active users anddividing by the number of required channels, in this example sevenchannels 20 a, 20 b, 20 c, 20 d, 20 e, 20 f and 20 g, resulting in the16.57 improvement factor, with a channel being defined as a stream ofvideo data being transmitted to one or more users 17 during any giveninstance in time.

Sharing of a stream of video information among multiple users 17 reducesthe cost required to distribute video information. Specifically, thenumber of communication pathways needed to distribute video informationto users 17 is reduced while increasing the number of users 17 that canview video information over a single communication pathway. This reducesthe quantity and complexity of the components and subsystems required totransmit video information while increasing a number of users that mayreceive the same. Although the foregoing has been described with respectto a window of viewing latency having a sixty second interval, inpractice, an interval of any duration may be employed, such as 10seconds, 20 seconds, 60 seconds or longer. As this interval isincreased, more efficient utilization of the video-on-demandarchitecture and other resources is realized, but users 17 experiencelonger lag times between a request for video content and receiving videocontent.

The more stream sharing is utilized, the more efficient the videodistribution architecture. With stream sharing capability, degradationwill never be worse than single session video-on-demand. The ultimatedegradation of multi-session video-on-demand converges to single sessionvideo-on-demand, and improves as more subscribers access the system. Itshould be noted that loading effects the efficiency of the multi-sessionvideo-on-demand architecture. The higher the loading, the higher theprobability for stream sharing. Specifically, as the video-on-demanduser 17 requests increase, the probabilities for increased architectureefficiency resulting from stream sharing increases significantly beyondthat available with single-session video-on-demand architecture. At theother extreme, when neither video-on-demand architecture requiresresources, none are allocated.

Referring to FIGS. 2 and 4, single-session video-on-demand architectureis compared with multi-session video-on-demand with all users 17selecting the same movie during a window of viewing latency. As can beseen by the slope of line 26, the number of channels required totransmit video program to users, in response to requests therefrom, isdirectly proportional to the number of users 17 for single-sessionvideo-on-demand architecture. The slope of line 28, however, indicatesthat the number of channels required is independent of the number ofusers 17 requesting to view the same. Request from users 17, however,may not be uniform, i.e., it will come in bunches. In this situation,the benefits provided by the multi-session video-on-demand architectureare greatly improved, dependent upon the statistical assumptionsconcerning the user 17 requests.

More particularly, the worst case statistical distribution for themulti-session video-on-demand architecture is the uniform distributionof user 17 requests, i.e., when the number of user 17 requests for agiven video program is uniform, or common, over an allocated timeinterval. This is shown when it is assumed that subscribers have nonotion of time and are not involved in otherwise scheduled broadcastevents that start and terminate on multiples of half hours.Specifically, it is widely believed that once video-on-demand users 17become accustomed to video-on-demand architecture, their interval timeawareness, as it relates to Pay-Per-View (PPV) surfing (browsing) willconverge to zero. If this is the case, then the bunchiness ofmulti-session video-on-demand is minimized, or non-existent. When thisoccurs, stream sharing continues to be beneficial, but its benefits areminimized. In this situation, multiple users 17 will share singlestreams information and therefore multi session will prevail as moreefficient than single-session video-on-demand. Furthermore, a uniformdistribution model of user 17 requests is an unlikely representation ofviewing patterns. The uniform model is depicted on FIG. 5 as line 30.

Referring to both FIGS. 2 and 5, the next statistical model employed totest the validation of multi-session video-on-demand is a purely randommodel, shown as line 32. The purely random model assumes the same numberof total users 17 as the uniform model, except some time intervals havemore users 17 transmitting requests than do the remaining timeintervals, with the differences being random. In other words, therequests are bunched into certain time intervals. This actually improvesthe efficiency of the multi-session video-on-demand architecture,because some time intervals will have more users 17 associated with acommon channel than other intervals. Some time intervals may not haveany activity what-so-ever, thereby maximizing efficiency.

Ultimate bunching occurs when a normal distribution, shown as line 34,of the users 17 are sending requests is assumed. As shown, thisdistribution assumes that periodically, e.g., every half hour, moreusers 17 are likely to start sending requests, because the users 17 havejust completed watching a video program, e.g., from perhaps a broadcastnetwork. The distribution assumes that no user 17 is perfectlysynchronized to transmit a request instantaneously after theaforementioned scheduled program terminated. These users might firstundertake some domestic activity, e.g., obtaining food to eat, but areloosely synchronized in the transmission of request to the managementworkstation 13. Further randomness can occur by totally random eventssuch as answering the door or phone. The subjection of the multi-sessionvideo-on-demand to this normal distribution provides more efficient useof the components and subsystems thereof, compared to single-sessionvideo-on-demand architectures. This is shown by comparing the area undereach line 30, 32 and 34, that represents a number of users participatingin stream sharing. The greater the number of sharing per unit time, themore efficient the architecture, with the area under all the lines 30,32 and 34 being unity. Thus, to efficiently employ multi-sessionvideo-on-demand, a statistical model is derived to optimize efficientuse of architecture resources while meeting the expected user 17 demandin much that same manner that the standard telephone company allocatesthe resources associated therewith.

Statistical modeling of information distribution systems is well knownand exemplified by telephone companies. It is well known that telephonecompanies have insufficient capacity to simultaneously satisfy therequirements of all its customers. For example, if telephone companypatrons attempted to use their telephone simultaneously, insufficientresources would exist to allow the patrons to complete a telephone call.As such, the telephone companies are organized to provide a costeffective approach to serve its customers based upon statisticallycalculated probabilities and expectations.

A similar statistical analysis is applied to the multi-sessionvideo-on-demand system to provide video-motion-control to the varioususers 17 thereof in a cost efficient manner which meeting statisticallydetermined expectations of the users 17. The statistical model employedfor multi-session video-on-demand is based upon certain operationalassumptions. These assumptions are that not all users are usingvideo-motion-control functionality concurrently; video-motion-controlresources are separate resources managed independent of the videocontent distribution resources; a pool of video-content-controlresources may be created which can be time shared among multiple users;and the shared finite video-motion-control pool is small compared to theusers 17.

The most significant usage characteristics that determine theappropriate size of the video-motion control resource pool are the typesof video-motion-control functions employed, the duration for which theyare employed and the time, relative to the playing time of a videoprogram, at which point they are employed. For example, a statisticalmodel created indicates that only a maximum of a couple of minutes, onthe average per video program, involves execution of certain basicvideo-motion-control functions: Play, Pause, Non Viewing Fast Forwardand Non Viewing Reverse. These functions require minimal bandwidth ofthe multi-session video-on-demand resources, because no digitalaudio/video MPEG channel resource is required to be dedicated to a user17. As such, the duration for which these video-motion-control functionsare employed need not be entertained, because neither avideo-motion-control-resource nor a video content distribution resourceis required. Fewer architecture resources are required if a Pausefunction is employed, because neither video-motion-control resources norvideo content distribution resources are required. Bandwidth need onlybe allocated to send a request to the management workstation 13indicating at which frame where in the video program the user 17 invokedthe aforementioned functionality. When the user terminates thefunctionality, bandwidth is required only to allow the managementworkstation 13 to find, or create, a video stream which will allow theusers 17 to continue viewing the video program so that the same appearsto the user 17 uninterrupted. Each of these requests takes only seconds.Similarly, non-viewing fast forward and reverse require only minimalarchitecture resources.

Complex video-motion-control functions, on the other hand, require agreat deal more bandwidth. As such, the amount of video-motion-controlresources is established as function of the Viewing Forward and Reverseusage. These functions include Viewing Fast Forward and Viewing Reverse.These functions require more bandwidth to execute, because a digitalaudio/video MPEG channel resource must be dedicated to a user 17 as wellas the capacity via the return data pathway receiver 23. For example, ifthe average full function video-motion-control user 17 requires twominutes a video program employing these functions, and if the averagevideo program duration is 100 minutes, then the averagevideo-motion-control user 17 will require 2% of the architecture'ssystems resources which Viewing Fast Forward and Reverse, assuming astatistically uniform distribution.

Were the statistical distribution of user 17's implementation ofvideo-motion-control functions not uniform, i.e., skewed or clustered,an assumption of 10% maximum concurrent utilization might be valid (5times worse than expected). However, the uniform distribution may not bean unlikely distribution of video-motion-control functions, because evenwith asymmetric (spasmodic) user 17 video-motion-control usage, byvirtue of the randomness between different video stream sequences andvariations in user 17 viewing behavior, there should be a predispositiontoward pure randomness, thereby contributing to a uniform distribution.Nonetheless, over-utilization of the multi-session video-on-demandarchitecture to occur would be exceedingly rare.

Many users 17 never employ video-motion-control except to pause for amovie (or employ non viewing fast forward and reverse). A simple poll of20 users 17 substantiates this assumption, because 1% of these users 17employed viewing video-motion-control functions on every video program.This further reduces the amount of required video-motion-controlResource.

Additionally, resources could be further shared if 15 second skips wereimplemented in viewing video-motion-control Forward and Reverse therebypermitting an additional compression of infrastructure by some smallinteger multiple (not 15 to one because only MPEG I frames would betransmitted, not B and P frames; and I frames are not as compressed as Band P frames).

Major moves forward and reverse into the movie could be provided withoutvideo-motion-control functions to further reduce the requirements on themulti-session video-on-demand architecture. This could include an EPGlike chapter and scene search capability. For example, an intra-movienavigation menu could be displayed with a list of chapters and indexedspecific content which could be directly selected and the system wouldtake the user 17 to that chapter or topic.

Lastly, video-motion-control functions are not required for users notcurrently using pay-per-view video-on-demand. For example, assuming thepercentage of video-on-demand users 17 active at one time is 15%, thatonly 50% of users 17 employ video-motion-control forward and reversefunctions and that the amount of time these users 17 actually employthese functions is 2% of the viewing time. Then the percent ofvideo-motion-control resources compared to video-on-demand video contentdistribution resources is only 1%.

In operation, the multi-session video-on-demand architecture istransparent to a user 17 in that its interface is similar to that of aconventional single-session video-on-demand architecture. The user 17reviews an on-line menu or program guide of available programs displayedon a video screen and selects a program. Very quickly, the systemresponds with the selection and begins to play it. In addition to theuser's ability to select content from a library of films or recordedevents, the user 17 is able to execute typical video-motion-control. Forexample, were a user 17 sharing a common stream with others, the user isproviding the functionality of pausing, fast-forwarding, or reversingthe contend of the video program that is in the stream, withoutdisturbing the video program being viewed by the remaining users 17sharing this common stream.

Upon executing a video-motion-control function, the user 17 is removedfrom the shared stream and given a private video-motion-controlresource, as defined above, but only for as long as required. Thislimited private video-motion-control resource comes, for a shortduration of time, i.e., a sub-portion of the bandwidth of the managementworkstation 13 video-motion-control pool, i.e., a large portion ofbandwidth of the management workstation 13, that may be dedicated toother users 17 of the same channel. The short duration of timefacilitates personal video-motion-control functionality to the specificuser 17 only so long as needed and which is subsequently returned to thevideo-motion-control pool. In this manner, N video-motion-controlresources may be shared by M users 17 at any one time and on any onechannel, where “N”<<“M”. Upon completion of video-motion-control, a useris switched to a stream of the video program, offset in time from theoriginal stream, with the offset in time corresponding to the portion ofthe video program in the stream which was being viewed by the user atthe completion of the video-motion-control function. In this manner, thevideo program associated with the stream of video information appearsuninterrupted to the user 17. If no such video stream is present, themanagement workstation 13 simply creates a new video stream to achievethe uninterrupted perception of the video program associated with thevideo stream that is also made available to users 17, as required. Wereoveruse of the multi-session video-on-demand architecture to occurthrough, for example, excessive requests for video-motion-controlfunctions, the multi-session video-on-demand architecture would displaya message to the user 17 indicating that VMC Resource Were NotAvailable, and the video stream would continue uninterrupted.

Should more content streams be required than a single DVEH/VP 16 a canproduce, automatic shelf space allocation in the video library 15 wouldbe carried-out. This may occur, for example, when more video programswere requested to be viewed by users than can be sold at any one time orthan the disks or disk arrays can produce. The solution therefore is tohave multiple copies of the movies on multiple disks or disk arraysavailable to multiple video pumps. Specifically, each DVEHNP 16 a is fedvideo programs from one or more disks in the video library 15. Were aDVEH/VP 16 a to utilize the entire capacity of a disk or disk arraycontained in the video library 15, multiple DVEH/VPs would requiremultiple disks or disk array duplicates of the same video program. Thus,to efficiently operate the multi-session video-on-demand architecture itis beneficial to ascertain the amount of additional copies of a videoprogram that should be provided an stored within the video library 15,referred to as automatic shelf space allocation. Automatic shelf spaceallocation is a business model optimization paradigm facilitatingcontent resources placement to be optimized to produce maximum revenue.Since content sales can vary hour by hour, day by day, holiday by nonholiday, optimum shelf space allocation can vary accordingly. Therefore,a content management function incorporated into the managementworkstation 13 includes two categories: Dynamic-Shelf-Space-Allocationand Barker-Channel-Programming.

Dynamic-Shelf-Space-Allocation is achieved by an algorithm programmedinto the management workstation 13 that specifics maximum shelf spacefor high grossing video programs while permitting low grossing videoprograms to have a lesser quantity of shelf space. The algorithm isreferred to as the Motion Picture Shelf Space Allocation Algorithm(MPSSAA) and is computed to automatically to provide minimum copies ofcontent and sufficient copies (shelf space) as expected for certainshowings based upon the following parameters:

actual system sales A gross theater sales B time content has beenavailable to C system (availability window) hour of day D day of week Econtent genre F studio or operator minimum shelf G space requirementsinterfering real time events H number of available digital channels Iscaling factors J local demographics K local content purchases L time Mdate N day of week or year O holiday P local operator shelf spacepreferences Q

-   -   such that the optimum shelf space value (Z {V}) for specific        content, where Z{V} is constrained by minimum and maximum total        available shelf space such that:    -   Min Shelf Space <fZ{V}< Max Shelf Space but the specific        computed shelf space value for each movie is:        -   I=m        -   Z{v}=f(A,B,C,D,E,F,G,H,I,J,K,L,P,Q,R,S,T)/n.        -   I=1    -   where n is a normalizing factor.

Referring to FIGS. 2 and 6, contractual constraints may be presented inwhich minimum values 40, corresponding to minimum shelf space that mustbe allocated, and maximum values 42 corresponding to maximum shelf spacethat must be allocated. The area 44 between the minimum 40 and maximum42 values represents operational latitude for operators with respect toallocation of the shelf-space. The management workstation 13 is designedto optimize revenue generation while maintaining operational head endprofits while operating within the operational latitude area 44,referred to as adapting room. This is achieved by dynamically adjustingthe scheduling of programming material on the video distribution systems16 so that, for example, the most profitable films are allocated thegreatest amount of shelf space. Conversely, the least profitable videoprograms are given the least amount of shelf space. To that end, themanagement workstation includes a multiple adaptive threshold element,shown in FIG. 7 in which the parameters previously defined, A through R,are inputs to logic block 50. Automatically computed weights for eachnode weight the inputs appropriately. Each video program's inputparameters are then multiplicity combined with the one set of weightscomputed for all video programs so that a set of shelf space values arecreated for each movie. One shelf space value is computed for eachmovie. These shelf space values are then ranked from minimum to maximumand shelf space is allocated accordingly.

The automatic adjustment of the weights is done iteratively during thesystem learning process, and as the system continues to learn how toautomatically optimize shelf space allocation, the iterative changes tothe individual weights becomes less and the system is said to beconverging (to an optimum set of weights). Of course, when new moviesare added, minor changes to the weights will again be required. Thistechnology includes video-on-demand architectures that adaptautomatically and architectures that adapt by group learning.

The shelf space algorithm system is designed to optimize operationalhead end profits while operating within the minimum and maximum shelfspace restraints by using information to automatically hone theoperation. Profit optimization is attained by providing the mostprofitable films the greatest opportunity to be selected (most shelfspace) while providing the least profitable films the minimum shelfspace within the minimum and maximum ranges specified.

These optimum shelf space values (Z{V}) are evaluated and ranked. Therewill exist one individual optimum shelf space value for each movie orprogram or event and one minimum optimum shelf space value. Theseindividual optimum shelf space values (Z{V}) are then ranked accordingto their values and correlated to shelf spaces available.

The movie with the maximum optimum shelf space value is given the mostshelf space while the movie with the minimum optimum shelf space valuesis given the least and movies with intermediate ranking are given shelfspace accordingly.

As represented earlier, one important indicator of the some of the videoprograms' predicted success is the theater box office sales and anotheris the actual system sales logged via the operator's set top boxes.These are probably the two most important parameters, however additionalsystem refinement is made possible by the other contributing parameters.

Some (but not all) of the elements of the optimum shelf space valuesare: pending real time events, theater box office sales, number ofavailable digital channels, demographic factors, content purchasedlocally, time of day, day of week, local operator preferences, holidays,program duration, avail window and duration, Movie Reviewer Ratings, andthe automatically adapting weights for each of these parameters. Fromthese parameters, an electronic spread sheet (matrix) is assembled whichautomatically computes the optimum shelf space values (Z {V}) for eachmovie or event. The events are then sorted according to their optimumshelf space values (Z{V}) which has been scaled in a range from 1 to 10where 10 is best.

Shelf space is allocated according to optimum shelf space values (Z {V})by the ranking of the optimum shelf space values (Z {V}) and weightingthem according experienced need for shelf space. In this manner, eachmovie can be assigned a fixed amount of shelf space and this shelf spaceallocation varies by time of day, actual sales, day of week, etc.Therefore, shelf space allocation can vary hourly, daily, or by otherperiodicity as desired by the operator.

The requirement exists for an automated Barker channel which isintelligent to the extent no advertising time is wasted showing Barkers(advertisements) for video programs started and which will not showagain for some time. The Barker channel, whose purpose it is toadvertise upcoming movies and/or events is most effective when heavyadvertising immediately precedes the expected start of the relevantvideo program event and may be employed during the window of viewinglatency.

Referring to FIG. 8, the provided maximum flexibility in distributingvideo programs, an All Demand Video Architecture 110 may be thatsupports all video transmission techniques multi-sessionvideo-on-demand, single-session video-on-demand, near-video-on-demandand scheduled programming. The All Demand Video Architecture 110 may bea software and firmware implementation relying on adaptive algorithms toeither optimize movie scheduling for near-video-on-demand, as disclosedin U.S. patent application Ser. No. 09/506,239 which is incorporatedherein by reference, or shelf space allocation for video-on-demand asdiscussed above. The All Demand Video Architecture provides GI Head EndEquipment 120 having a library of movies contained therein on multiplefiber optic OC3 channels at 155.52 Mbps per channel, delivering theappropriate movie to the correct user 117 via an internal routing systemand controlled by the Management Workstation. The switching does notrely on expensive OC3 switches, rather it employs internal and inherenttime division and space division multiplexing to permit any movie to bedelivered to any user 117. An N X M SCSI space division switchingmechanism is combined with time division multiplexing by the DEHV/VPs116 over a PCI bus in the Digital Video Engine Hosts.

The All Demand Video Architecture 110 provides content and control tothe Head-End equipment. It further permits partitioning and dedicatingmultiplexors and modulators to different neighborhood nodes 121, andultimately to different users 117, which is currently not facilitated byexisting hardware. The return data path (RPD) 123 from the Set Top Boxes(not shown) of the users (117) to the Head End and All Demand VideoArchitecture 110 employs standard RPD hardware, but this RPD hardware isnow connected to a transaction computer 119, via a router 129 to permitthe control of the overall system. In this fashion, the All Demand VideoArchitecture 110 permits five modes of operation shown in FIGS. 8 and 9.

1. A method for storing video programs in a video library in avideo-on-demand system, the method comprising: defining a plurality ofdynamic demand parameters, wherein the plurality of dynamic demandparameters includes theater box office sales and sales via thevideo-on-demand system: assigning a weighting factor to each of theplurality of dynamic demand parameters; assigning values to each of thedynamic demand parameters for each of the video programs; calculating ashelf space value for each of the video programs using the values forthe dynamic demand parameters and the weighting factors; and allocatingstorage space in the video library for each of the video programs basedthe shelf space value of that video program.
 2. The method of claim 1,wherein the plurality of dynamic demand parameters further includes oneor more of: duration of the video program availability to thevideo-on-demand system; current time; current weekday; current date;holiday and special event information; video program genre; videoprogram ratings by movie reviewers; studio-imposed minimum shelf spacerequirements; operator-imposed minimum shelf space requirements;operator preferences; intervening real time events; number availablechannels in the video-on-demand system; scaling factors; and localdemographics.
 3. The method of claim 1, wherein calculating a shelfspace value for each of the video programs comprises: multiplying thevalue of each dynamic demand parameter for the video program by theweighting factor for that dynamic demand parameter to generate aweighted value for that dynamic demand parameter; and adding togetherthe weighted values for each of the dynamic demand parameters of thevideo program to determine the shelf space value for the video program.4. The method of claim 1, wherein assigning the weighting factor to eachof the plurality of dynamic demand parameters comprises adjusting theweighting factors until a desired performance parameter of thevideo-on-demand system is optimized.
 5. The method of claim 4, whereinthe desired performance parameter is revenue generation.
 6. Avideo-on-demand system comprising a management workstation forcontrolling video program storage in the video-on-demand system, themanagement workstation comprising: a plurality of adaptive thresholdelements for multiplying a set of dynamic demand parameters for eachvideo program by a set of weighting factors to generate a set ofweighted demand values for each video program, wherein the set ofdynamic demand parameters comprises theater box office sales and salesvia the video-on-demand system; summation logic for adding up the set ofweighted demand values for each video program to generate a shelf spacevalue for each video program; and allocation logic for assigning storagespace to each video program based on the shelf space value for thatvideo program.
 7. The video-on-demand system of claim 6, furthercomprising iterative logic for adjusting the weighting factors until adesired performance parameter for the video-on-demand system isoptimized.
 8. The video-on-demand system of claim 6, therein the set ofdynamic demand parameters further includes one or more of: duration ofthe video program availability to the video-on-demand system; currenttime; current weekday; current date; holiday and special eventinformation; video program genre; video program ratings by moviereviewers; studio-imposed minimum shelf space requirements;operator-imposed minimum shelf space requirements; intervening real timeevents; number available channels in the video-on-demand system; scalingfactors; and local demographics.